The amount of security relevant news and information published on a daily basis increases rapidly. It is no more a background task for a system administrator to read this information and act in response to it. Even security services and compacted security news sources have the disadvantages of offering too much information causing a large time delay between time received and time read. Therefore the time between public knowledge and acting in respect of said security relevant information is increasing. This is also due to the fact, that the security or vulnerability information is published at different time zones during daytime, at night and over weekends. The growing window of vulnerability increases the chance of attack. The attacking by system crackers is described by James Riordan in “Patterns of network intrusion”, Günter Müller and Kai Rannenberg, editor, Multilateral Security in Communications, Information Security, pages 173-186, Addison-Wesley, 1999. System crackers build large databases of what versions and revisions of software various systems are running. With this knowledge crackers can immediately react on announcements of vulnerabilities with a wide scale of exploitation of this vulnerability. In order to prevent exploitation of vulnerability, the administrator has to shut down, restrict or replace at least one service of the system. An other possible reaction is installing patches or upgrades without the discovered security problem. Since the system administrator has difficulties to cope with the increasing amount of security information, taking or at least suggesting measures could be done by a security service provider. The service provider could provide several clients with information on relevant measures for their systems. Since the service provider would be contacting the vulnerable system from outside, there will be the need of cryptographic security. The service provider would have to know the exact characteristics of the clients systems. This external knowledge and the possibility to find out what groups of clients receive the same information about necessary measures, could supply system crackers with information about vulnerabilities of the clients systems.
A concept for secure shutting down of mobile services is described by Christian Tschudin “Apoptosis the Programmed Death of Distributed Services”, in J. Vitek and C. Jensen, editors, Secure Internet Programming—Security Issues for Mobile and Distributed Objects, pages 253-260, Springer, 1999. Active networks with services run by mobile code have to have the functionality of creating and ending services. The apoptosis concept of self-destructing mobile services is borrowed from cell biology and designates there the programmed cell death. The apoptosis process is suggested to start as for cells by two different ways. A service may depend on a continuous stream of credentials or positive signals. Once these credentials run out, the service will shut down. According to the second way a negative signal causes the service to shut down. The apoptosis entry point of a mobile service would be a primary target for an attack. Therefore the apoptosis concept should be implemented with cryptographic security functions. Cryptographic security functions are described by J. Riordan and B. Schneier, Environmental Key Generation Towards Clueless Agents, in G. Vigna, editor, Mobile Agents and Security, volume 1419 of LNCS, pages 15-24, Springer, 1998. The shut down has to be induced by an apoptosis activator. Applying the above mentioned apoptosis concept does not change the disadvantage that a system administrator or a security service provider has to induce the shut down procedure.
U.S. Pat. No. 5,978,484 describes a method and system for distributing and executing executable code. This method is applied in a client-server environment in which executable objects are downloaded or otherwise distributed from a distributing authority and executed on a different computer. While it is very desirable for a client to execute server-provided software, the potential threat to security is a serious drawback. For a client to be willing to execute server-defined functionality, the client must be assured that no adverse effects will occur. Specifically, there must be a guarantee that existing client data will not be read or modified and that hostile code (viruses, Trojan horses, etc.) will not be generated and installed on the client system. Since server provided programs would have access to the full resources of the client computer environment, they could potentially perform any of various different types of dangerous or hostile operations. Binary executable code also has the disadvantage of being architecture specific. It is a significant complication for the server to determine the computer hardware in use by the client and the operating system, and to provide different executable modules for use with different systems. These issues lead naturally to consideration of an interpreted language. This approach allows a server to create program scripts that can be executed on the client to extend its functionality, while providing a more controlled execution environment and architecture neutrality. Interpreter systems, as for example Java, allow the generation of complex applications including I/O operations and rely on trust relationship between the server and the client. In order to eliminate the requirement of a trust relationship the invention of U.S. Pat. No. 5,978,484 classifies different types of security related operations and services, which might potentially be performed by externally provided code, into different categories. When providing executable code, a distributing authority also provides a privilege request code, indicating a set of privileges or privilege categories that the executable code might perform on the client machine. The distributing authority digitally signs the executable code and the privilege request code, and also provides a certificate that can be traced by the client to a known certifying authority. The certificate indicates an authorized set of privileges that the distributing authority has been authorized to include in distributed code.
If a solution according to U.S. Pat. No. 5,978,484 would be used to prevent exploitation of vulnerability, the distributing authority would have to transmit code and the privileges for shutting down, restricting or replacing insecure services at the client. Since the vulnerability depends on the actual characteristic, specification or version of the service, the distributing authority would need to know this information for any client service at any time accurately. The chance that a service or underlying code is updated at a client without reporting it to the distributing authority is rather high. Without accurate information about all services secured by the distributing authority, the distributing authority can not guarantee a security service. An other disadvantage of a security service supplied by a distributing authority is the fact that information about characteristics, specifications or versions of the services transferred from the services to the distributing authority and information about security measures transferred from the distributing authority to a service could be used by system crackers.
U.S. Pat. No. 5,825,877 describes an other solution for the delivery of software through distribution systems such as networks. This solution provides a form of authentication wherein a trusted third party signs a certificate to identify the author of a program and to secure its integrity. The program code is encapsulated or otherwise associated with the certificate and an access control list. The access control list describes the permissions and resources required by the code. An enforcement mechanism allocates system permissions and resources in accordance with the access control list. Upon downloading the code and the access control list with the corresponding certificate a verifier first checks to see if the certification agency's signature on the certificate is valid (using the certification agency's known public key). The verifier then computes the cryptographic hash of the code/access control list and verifies that it matches the value in the certificate. If the signature is not valid or the hash does not match, the code and the access control list are rejected. If the verification is ok, an access control list manager is invoked. The access control list manager displays the access control list to the client via a client interface and ascertains whether the client wishes to allow or disallow the individual items in the access control list. The access control list manager stores the code as directed by the client via the client interface and stores the access control list together with permission flags. The access control list consists of two parts: the physical resource table containing the physical resources required by the code and the logical resources table containing the permissions and logical resources required by the code. If such a solution would be used for shutting down, restricting or replacing insecure services at a client system, it would have the same shortcomings as described in respect of a solution according to U.S. Pat. No. 5,978,484.